查看原文
其他

微服务失败重试(2)AWS 消息服务选型对照表

薛以致用 AWS 架构师之旅 2019-12-18

目前开源和 AWS 原生的消息中间件特别丰富,客户常常不知道如何如何选择,本文整理了一张表,具体应用场景可以对照来看哪个是最适合消息系统;对于应用依赖的关键特性建议再对照官方文档和咨询原厂技术人员。



特性Amazon SQSAmazon SNSAmazon MQAmazon EventBridge
Release Date
发布日期
2006.072010.042017.102019.07(由CloudWatch Event 演进而来)
Entity Type
消息机制
Queue (Similar to JMS)
消息队列服务
Topic (Pub/Sub system)
发布订阅
Managed Service for Apache ActiveMQJSON 消息
规则订阅
Message Consumption
消费机制
Pull Mechanism
轮询
Push Mechanism
推送
JMS, NMS, AMQP, STOMP, MQTT, and WebSocket.

Point-to-point (message queues), publish-subscribe(topics), request/reply, persistent and non-persistent modes, JMS transactions, and distributed (XA) transactions
Push Mechanism
推送
Persistence
持久化
消息保存在跨可用区分布式存储,最多保存14天
Messages per queue (backlog) =  Unlimited Storage 无限
Messages per queue (in flight) = Max 120,000 Msg, FIFO Max 20,000 Msg (读取但未删除的消息数)
Messages per queue (in memory) = FIFO Max 20,000 Msg
SNS provides durable storage of all messages that it receives.
也提供了跨可用区的持久存储
支持:非持久模式/快速使用者/批处理事务
Multiple Availability Zones (AZs) redundantly stored
多可用区冗余存储

99.999999999% (eleven 9’s) message durability
11个9持久性
SLA 99.99%
Types of Supporting Endpoints
支持的消息消费者服务或协议
您可以将 Amazon SQS 与 Amazon EC2、Amazon EC2 Container Service (Amazon ECS) 和 AWS Lambda 等计算服务以及 Amazon Simple Storage Service (Amazon S3) 和 Amazon DynamoDB 等存储和数据库服务结合使用,从而让应用程序具有更高的灵活性和可扩展性6 种类型的目标:“HTTP”, “HTTPS” | ”Email”, “Email-JSON” | “SQS” | "SMS" | Mobile Push Notifications | Lambda Function各种消息协议的客户端有 90 多项 AWS 服务可以用作 EventBridge 的事件源
有超过 15 项 AWS 服务可以用作 EventBridge 的事件目标,其中包括 AWS Lambda、Amazon SQS、Amazon SNS、Amazon Kinesis Streams 和 Amazon Kinesis Firehose
Max Message Size 
消息大小
256KB文本(支持引用S3对象的消息最大2GB)256KB (Except for SMS Message)可配置,100KB 上下,持久性存储的延迟和吞吐对性能有影响256KB(Reqest 大小)
Delivery Reliability
消息传输的可靠性
延迟 0 ~ 15 秒
标准队列至少一次
FIFO 仅一次
支持长轮询(默认20秒,避免空消息)
典型延迟不超过 30 毫秒
Most time exactly once to subscribers. 
大多数情况仅一次
Msg Orders best efforts to match publisher orders
最大程度保持顺序
A automatically retry patterns (linear, geometric, exponential backoff)
自动重试机制
取决于消息大小,实例大小和存储特性典型时延半秒
Retry Pattern Example
如何处理失败重试
死信队列保存“毒丸”消息SQS (subscribing endpoint): If a SQS queue is not available, SNS will retry 10 times immediately, then 100,000 times every 20 seconds for a total of 100,010 attempts over more than 23 days before the message is discarded from SNS.
(1)立刻重试10次(2)每隔20秒重试一次,总计不超过10,000次 (可最多持续23天)

Lambda: If Lambda is not available, SNS will retry 2 times at 1 seconds apart, then 10 times exponentially backing off from 1 seconds to 20 minutes and finally 38 times every 20 minutes for a total 50 attempts over more than 13 hours before the message is discarded from SNS.
(1)每隔1秒钟,重试一次,总共2次(2)接着随机在1分钟~20分钟选一个时间间隔重试不超过20次(3)每隔20分钟再重试38次;总共50次尝试,持续最长12个小时的重试尝试。
支持自定义重传策略和死信队列
支持失败自动重试,最长事件消息保留24小时左右
默认重试策略,利用指数退避算法,最多重试次数在185次左右
API Limits
API 调用限制
标准 队列每个 API 操作支持接近无限的每秒事务数 (TPS)订阅筛选策略 -200 每个账户
发布 - 300次/秒 ~ 30000次/秒(不同区域不一样)
Connections per wire-level protocol:1,000 (100 for mq.t2.micro brokers)
每个代理用于其他实例类型的存储容量200GB,mq.t2.micro 代理的存储容量 20GB
每个代理250用户
每个用户20组
PutEvents - 400 次/秒(可提升);其他50次/秒
目标触发调用 - 750次/秒
每个规则最多5个目标
Message Filtering
消息过滤能力
不适合Filter Policy based on Message Attributes, for SQS subscribing endpoint, a max 10 name-type-value allowed支持Amazon EventBridge 使用基于 JSON 并且明确的事件结构,让您能够创建应用于整个事件正文的规则,以便选择要发送到目标的事件。
Message Delivery Status
消息传递状态
不适合Support Logging delivery status to cloudwatch logs不适合不适合
Pricing Model
价格模型
Lightweight, fully managed
轻量级纯托管

Amazon SQS 的费用按请求数计算,再加上从 Amazon SQS 传出数据的数据传输费 (传输到同一区域内的 Amazon EC2 实例或 AWS Lambda 函数的数据除外)。
Lightweight, fully managed
轻量级纯托管

Publishes by 1 million request units 
每100万个发布消息
Notification Delivery  (No charges for SQS & Lambda Functions)
消息通知(对于 SQS 和 Labmda 函数免费)
Data Transfer Out of SNS ( Free between EC2 & SNS within the same region)
数据传出SNS(EC2 和 SNS 同一个区域免费)
Per Broker Instance(EC2)
每个实例
Per storage (GB-month)
存储(GB月)


每100万个发布事件
Common User Scenarios
常见用户场景
适用于微服务、分布式系统和无服务器应用程序的完全托管的消息队列;Amazon SQS 可以大规模处理工作,每天处理数十亿条消息。SNS + SQS to build 1:N system compontents architecture
Mobile Device & Applications notifications
Industry-standard APIs and protocolsAmazon EventBridge 是直接与第三方 SaaS 合作伙伴集成的唯一一种基于事件的服务构建的应用程序需要对来自 SaaS 应用程序和/或 AWS 服务的事件做出反应,建议您使用 Amazon EventBridge


“微服务失败重试”系列展望:



近期原创:


    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存